The present invention relates to software auditing systems and, more particularly, the invention concerns a method and system for monitoring the use and non-use of software programs.
Licensed software products, such as those from IBM, Computer Associates or Microsoft, are typically composed of a number of discrete executable components: exe-files, batch files, JCL, etc., herein collectively referred to as modules. A typical mainframe computer might have 500 products, composed of 500,000 modules on 3,000 libraries, often with many of the products duplicated on a number of libraries. While many software products are installed in default libraries specified by the vendor, some installations choose to link the more commonly used products into the system libraries.
Prior Isogon patents have described techniques for performing software auditing, including the steps of Surveying (scanning all hard-drives or disk storage for modules), Identification (deciding, for each module on each library, what software product it belongs to) and Monitoring (intercepting and recording all module executions). As described in those patents, and as practiced by Isogon's software auditing product, SoftAudit, the steps of Surveying, Identification, and Monitoring are both interrelated and separate processes.
The SoftAudit Monitor is also described in the present Assignee's issued U.S. Pat. No. 5,590,056, the contents of which are incorporated by reference herein. The SoftAudit Monitor collects usage data for (virtually) every load module executed within the system (image, LPAR). This usage data is correlated to survey and identification data to ultimately determine and report which software products, and the libraries in which they are installed, have and have not been used.
For the MVS and OS/390 operating systems, it does this by intercepting the LOAD, LINK, ATTACH, and XCTL system functions. Whenever such a function is invoked, the Monitor creates an entry in a memory table which relates the module usage to the job/job step/started task/TSO session (hereinafter, process) for which the module was loaded. Eventually, the usage data is written to external media (either when the memory buffer needs to be reclaimed, or on an hourly basis) and subsequently correlated with other data as previously described.
Due to the high number of executing modules, both the volume of data recorded and the processing time used can become excessive. In other situations, such as with different operating systems, intercepting system calls may not be practical or would greatly impact system response times.